Subject: Electronic AP for DLSw Multicast

From: [email-masked]
Date: Mon, 23 Sep 96 08:37:05 EDT

Dave, Thanks for the replies and all your efforts.  Comments below.

Jon Houghton (IBM Corporation)

>> ------------------------------- Referenced Note ---------------------------
>> Received: from www.raleigh.ibm.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP;
>>    Thu, 19 Sep 96 20:56:51 EDT
>> Received: from localhost.raleigh.ibm.com by www.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03)
>>           id AA15759; Thu, 19 Sep 1996 20:56:31 -0400
>> Date: Thu, 19 Sep 1996 20:56:31 -0400
>> Message-Id: <[email-masked]>
>> Errors-To: [email-masked]
>> Reply-To: [email-masked]
>> Originator: [email-masked]
>> Sender: [email-masked]
>> Precedence: bulk
>> From: David.Bryant/HQ/[email-masked]
>> To: [email-masked]
>> Subject: Electronic AP for DLSw Multicast
>> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
>> X-Comment:  DLSw scalability issues
>>
>> Sorry for the delay in responding guys... some long needed
>> vacation and work crisises kept me away.
>>
>> Sounds like I'm going to have to put out a new version of
>> the document to address some of the (very valid)concerns brought
>> up.  So please get me your comments on these proposed changes
>> by 9/25 and I will get a new verision of the spec out by 9/27
>> and will want go AP on it if there are no substantial objections
>> by 10/11.
>>
>> Here's a list of the issues (as I read them) and responses:
>>
>> 1).  What are we asking AP approval on
>>
>> I'm asking for AP status on the DLSw Multicast proposal only.
>> The current plan (as discussed at the AIW)is that we will try
>> to gain AP status on DLSw Multicast at AIW 11 (now occurring
>> electronically).  Then Paul Brittan will create a new document
>> containing the DLSw Multicast proposal and other approved DLSw
>> changes into a single DLSw Version 1.1 document for CP approval
>> at AIW 12 (Nov '96).  This latter item is looking less likely
>> every day.  And, I have not as of yet received any indication
>> from Paul that he will be able to create the DLSw Ver 1.1 spec.
>> in the time necessary to receive CP at AIW 12.

OK.

>>
>> 2). Single Tunnel activation with DLSw Multicast
>>
>> You guys are right.  I went into the document and changed the
>> read port to 2067, but didn't look closely enough at what I was
>> doing to realize I need to add clarification text.   It is my
>> intent to say that DLSw Multicast nodes should establish a single
>> TCP connection on 2067.   This still leaves a potential race
>> condition whereby two DLSws bring up connections to 2067 at the
>> same time.   In this case, the DLSw with the higher IP address
>> must tear down it's connection after the capabilities exchange
>> using a new reason code: x'000E' - unnecessary excess connection
>> terminated
>>
>> This shouldn't create a problem when connecting to down-level
>> (non-multicast) DLSw's because these types of connections must
>> be predefined anyway.  So the DLSw should know to use the RFC
>> 1795 method.
>>
>> Clarifying this will take some text in several places in the
>> document... so it sounds like I'm sending out a new updated
>> version.  Please give me your comments by 9/25, before I bother
>> to do so.

In the minutes of AIW 11, it is stated that a separate proposal on
the bringing up of a single TCP pipe is to be available within
2 weeks of the AIW.  "If the proposal was too late ...., it was
not felt worth delaying v1.1 over this issue."

Are you now accepting responsibility for this proposal and trying
to merge it into the scalability document?
We feel that this should be feasible, but are worried that it could
drag out approval of this document - it is likely to take a few
rounds of reviews and comments to nail down.

If the group does choose to go this route, we would like to make
sure the following questions and issues are addressed:

1) If the read port is 2067, what is the write port?  Our assumption
is that the write port is also 2067.  This makes TCP responsible for
handling race conditions - DLSw should not have to do anything.
If the write port is 2065, there could be race conditions that should
be handled by DLSw and their handling needs to be documented.

2) As you've already mentioned, it needs to be stated explicitly when
read port 2067 is used.  We are assuming it is as you stated:
If the partner is known to be multicast capable, send to read port 2067,
otherwise send to read port 2065.

3) It should be stated what is required support and what is optional
support.  Obviously (we think), it is required to support listening on
read port 2067.  But is it required to send to read port 2067?
Or could an implementation continue sending to read port 2065 and bring
up the connection the current way to a multicast capable partner.
Saying it is optional gives implementations more flexibility, but
opens up some race conditions.

One note : it is likely that even if the document states that it is
required to send to read port 2067 for all multicast capable partners,
implementations which support both types of partners will still
have to handle the possibility of receiving on read port 2065
from multicast capable partners (customer configures multicast capable
partners as partners, incomplete information about partner, ...).

4) Do we need to document the race condition alluded to above.
One partner is bringing up a connection from 2067 (or 2065) --> 2067.
The other partner is bringing up a connection (perhaps a configuration error)
from 2067 --> 2065.  If this race condition is to be handled, we should
document which session is dropped and by whom.

Note - I would not recommend using Neg Capex in these cases.  The
TCP connection race conditions should be resolved prior to Capex.
The Neg Capex should only be used to indicate a problem in the partner's
Capex Req.

5) Even though receiving a connection to read port 2067 implies that
the partner is multicast capable and one TCP session is being used,
it is assumed that these CVs in the Capex should still be present.

We all agreed at the last AIW that things could only be improved
by bringing up only 1 TCP session instead of bringing up 2 and dropping 1.
But as we near CP on this document, our eagerness to hurry this function into
this release of AIW function goes down - at some point, it is too late.

I think we need some idea from others on whether there is still interest
in adding this function.  Please append your thoughts so that Dave
knows to continue.  From our point of view, if the above points are
addressed appropriately in the document, we are willing to push it in.

>>
>> 3). UDP Packet parsing
>>
>> Sounds like there's some concern over the text describing how/when
>> to ignore imbedded control vectors. I put this in because that was
>> (and always is) the working assumption in RFC 1795 (and SNA).
>> But it was never documented.  It's purpose with respect to this
>> document is currently not needed, but might be in the future.
>> I figured putting it in now, might help avoid problems or at least
>> establish a way to rule on who implemented correctly in the future.
>> I advise keeping it in, but am ambivalent.   Since it seems
>> to create some level of concern, the easiest thing to do is remove
>> it.  I propose to do that unless someone strongly wants it in
>> (and let's me know prior to 9/25).

As I said before, I don't have strong feelings on this one - but I
lean toward your idea of removing it.  It is a strong enough paragraph
that it makes the implementer want to comply - there's just nothing to do.

>>
>> 4). NetBIOS transport chart updates
>>
>> I'm ok with the suggested updates (basically saying unicast vs.
>> multicast is an implementation issue based upon whether the sending
>> node has cached enough information to determine which is necessary).
>> I'm also ok with simply deleting the statement regarding DATAGRAM
>> frames and whether they flow as DATAFRAMEs or DGRMFRAMEs.  This is
>> covered in RFC 1795 and need not be covered in the multicast document.

Sounds good.

>>
>> 5). Vendor Specific UDP packet
>>
>> Couple issues here.
>>
>> 5.1). Header length
>>
>> The header length should be at least 7 and could be higher if the
>> vendor chooses.  I will add text accordingly

OK.

>>
>> 5.2). Message type following OUI
>>
>> I don't think this is necessary.  I think the easier thing to do
>> is to simply strike the statement that AIW standards will
>> use an OUI of zeros.   This way we'll leave AIW standard UDP packet
>> formats to be defined later.   We also potentially save 3 bytes
>> on each packet.

If this is the preferred route, it is OK with me to defer this
entire discussion.  It just seemed simpler to go ahead and address
it now before vendors implement their own messages.
But I won't push this one either.

>>
>> 5.3). Clarification text
>>
>> Sounds like folks want more text clarifying the fields of the
>> vendor specific UDP packet header.   I'll do this, but it will
>> be pretty simply now.  I'll add text that the header length is
>> always 7 or higher.  I'll remove text regarding AIW standards
>> using zeros.   Is there anything else anybody feels I should add?

Again, if the reason for having a header length and message length
is to handle the case in which one of these frames makes it into
the TCP stream, then it is mandatory that the header length plus
the message length add up to the total length of the data following
the IP/UDP (or IP/TCP) headers (i.e., total length of DLSw data).

>>
>> 6). Typos etc.
>>
>> - I found and agree with all but "Single session TCP connections:
>> section; first paragraph, first sentence... where's the error?

There are two sections with very similar titles.  The sentence I
was referring to was ...
"RFC 1795 defines a negotiation protocol for DLSw to chose ...."
                                                    -------

>> - "Vendor Specifi Functions over UDP"; second paragraph, first
>> sentence... what second paragraph?
>> - change "set of DLSw" to "set of DLSws"... couldn't find,
>> where is this? Found and corrected this under "Unicast UDP
>> Datagrams"

My mistake.  That heading was wasn't spaced on my print out and
I missed it.  You got the one I was referring to.

>>
>> 7). DLSw Discovery
>>
>> That's a seperate topic that I'll leave to those with an interest.
>> I suggest this discussion be moved outside the DLSw-scalability Riglet.

I agree 100%.  Sorry I mentioned it - just trying to give some reality
to my desire to standardize some small portion of the DLSw UDP frame
following the OUI.

>>
>> Anything else???
>>
>> Regards, Dave
>> PS.  Boy will I be glad when this is done!

I'm sure - I hope the single TCP session stuff doesn't drag this out.